NetWare Loadable Module
part 2/7 · 11.5 KB total
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Contents
• See also
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Functionality
Upon loading, a NLM requests resources, such as memory and process threads, from the NetWare kernel. The NetWare kernel tracks such requests, and can identify memory and other resources assigned to a specific NLM. NLMs may auto-load other NLMs upon which they themselves depend.
NLMs may register commands with the NetWare kernel, extending the command vocabulary available at the NetWare console prompt.
When properly coded, NLMs can be re-entrant, allowing multiple instances of the same code to be loaded and run.
Programming issues
Initially, Novell published a development toolkit for NLM programming including kernel API documentation and a C compiler (Watcom), but third-party support for the NLM executable function was very limited.
In early NetWare versions (prior to v4.x), all processes were executed in the kernel address space, without specific memory protection. It was therefore possible for bugs in NLMs to overwrite the kernel's or other NLM's address space and ultimately crash the server — in the mainframe-derived Novell terminology, this was known as an ABEND or ABnormal END.
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────